1. Field of the Invention
The present invention relates to processors in general and particularly to the administration of intermediate results in jumps to a sub-program.
2. Description of the Related Art
The operation of processors is controlled by programs, which consist of several commands. In the easiest case, the processor processes the program from beginning to end in a linear way according to a predetermined processing sequence, without passing through any program parts several times. Therefore, the program is stored and disposed, respectively, in a linear way in the physical memory or, in the case of a virtual memory addressing, in the virtual address space.
For avoiding the repeated storage of identical program parts with an identical sequence of commands, however, programs have at least so-called sub-program jump commands (CALLs), and when they occur, processing is continued in part of the program, a so-called sub-program, until a return occurs in the sub-program, whereupon the execution of the program is continued at the location which succeeds the sub-program jump command according to the processing sequence. In that way, the memory required for storing the program is reduced to the one required for storing the commands of the sub-program as well as the jump commands compared to the memory, which would be required to store the complete sub-program each time.
During processing the program, the processor generates intermediate results, which it writes into internal registers of the processor. These internal registers are, on the one hand, faster writable and readable, respectively, than external memories available for the processor, such as a RAM or an EEPROM, but are, on the other hand, very limited in their memory capacity, since they are expensive. To really allow full access to the fast internal memory of the processor during processing the sub-program, it has to be made sure during the programming of the program, that those intermediate results in internal registers, which are still required in the mother and main program, respectively, after processing the sub-program, will not get lost by overwriting these internal registers during processing the sub-program.
A first and at the same time easiest possibility for backing-up intermediate results in the internal registers during the length of the sub-program is to provide memory commands in the program code in processing sequence prior to the respective program branch command and the jump command, respectively, which store the register contents sequentially, register by register into a memory location secure from overwriting, such as an external RAM. One example of such a memory command is, for example, the command MOV <memory location address>, Rx, wherein the common notation for commands is used and the operand <memory location address>indicates the address of the memory location, where the register content of the register Rx is to be stored. A disadvantage of this procedure is that one or according to data organization, even several commands are required per intermediate result to be stored and per register, whose content is to be stored, respectively, so that the length of the program code and, more exactly, the requirement of code memory per program branch is increased significantly.
An improved possibility for backing-up register content for the length of the sub-program is to use specialized commands for pre-storage of the register contents to be backed-up, which store the register contents to be backed-up not individually but in groups or at once in the back-up memory provided therefore. An example for such a memory command is, for example, a multiple push operation and a multiple filling operation, respectively, such as, written in common notation, Push <Rx, Ry, Rz . . . >, whereby the register contents of the register s Rx, Ry, Rz . . . are entered into a stack provided therefore. Although the requirement of command lines in the program code is reduced to a single memory command by summing-up several memory commands, there are still at least two command lines required for preparing the processing of the sub-program, namely the multiple memory command and the program branch command.
A last possibility for backing-up register contents for the length of a sub-program is an automatic recognition of the data and register content to be backed-up, respectively, by logging those registers which have been written with intermediate results prior to the jump command. According to this possibility, the register contents of the accordingly recognized internal registers are automatically counted to the “data to be conserved” when a branch command occurs, i.e. backed-up to a stack or another back-up memory, which is not as much subject to the size restrictions of the internal registers. Although in the last-named possibility of data back-up, merely one command line and one branching command, respectively, is required in that part of the program from which the jump to the sub-program is performed and which is referred to as mother program below, it is a disadvantage that in the automatic recognition it cannot be considered, which of the data stored in the internal registers during the execution of the mother program have to be available after processing the sub-program and which not, so that the back-up storage for backing up these data is wasted and a larger than absolutely required back-up memory is required, respectively.
As has already been mentioned, a return command in the sub-program corresponds to the jump command in the mother program and, upon occurrence of the return command processing is continued at the command succeeding the sub-program jump command in the mother program. Here, commands for restoring the data needed for further processing the mother program are required, in correspondence to the commands of the pre-data back-up in the jump command.
A possibility for data restoration corresponding to the above first described possibility are simple loading commands, such as MOV Rx, <back-up location address>, which are equivalent to the memory commands. A variation corresponding to the second possibility uses, for example, a multiple-pop-command and a multiple-output-command, respectively, such as pop <Rx, Ry, Rz . . . >, whereupon a number of register contents corresponding to the number of registers Rx, Ry, Rx . . . is taken from the stack and entered into these registers. In the case of using the last-named possibility for data back-up of jump commands, the register contents to be restored are automatically restored upon occurrence of the return command (such as RET) and written into respective internal registers, respectively, wherein the information, which of the registers have been backed-up automatically and, in other words, how many register contents are to be taken from the back-up memory, and into which registers same are to be written, are already stored in the back-up memory together with the register content to be backed-up during processing the “automatic jump command”.
The previous discussion with regard to the return command from the mother program to the sub-program has illustrated that the problem of the requirement of command lines for backing-up data to be restored in the registers occurs again after processing the sub-program, whereby the requirement of command lines is doubled in total.
Although the problem of the additional requirement of command lines when calling sub-programs is only a small problem in view of the rapid development of the memory technologies in most applications, such as personal computer applications, there are memory restrictive fields of application where the program memory for storing the program code is extremely limited in multiple ways. One example of such a field of application are chip cards, such as used in cashless payment systems. Industrial standards determine the available chip area, which again limits the available memory capacity. The problem is increased by high security requirements, which require extremely expensive and thus large-area crypto processors for the calculation of the extremely computation-intensive cryptoalgorithms. Additionally, chip cards are required to have a high degree of user friendliness, part of which is a terminal time period, which is as short as possible. To enable fast terminal time periods, cryptographical computations have to be parallelized, which requires a trade-off between required chip area, required computation time of the crypto co-processors and underlying key lengths. Above that, some chip card applications provide a transfer of program codes, namely from terminal to chip card, so that here, due to the limited transfer rate, a reduced program code length is desirable for shorter terminal time periods. Accordingly, the latter holds true, of course, for other fields of application, such as the transfer of program codes to satellites or the like.